1. Field of the Invention
The present invention relates to computer systems; more particularly, the present invention relates to computer systems operable in system management mode.
2. Description of Related Art
System management mode (SMM) allows systems developers to provide low level functions, such as power management or security, in a manner that is transparent to operating systems and application programs. SMM allows operating system and application software operation to be interrupted to perform these low level functions. After performing the low level function, the operating system or application software operation is resumed from the point that it was interrupted.
In order to initiate a low level function, a hardware interrupt, referred to herein as the System Management Interrupt (SMI), is generated. When an SMI is received, the processor waits for all pending writes to complete. The processor also waits for writes pending on external devices, such as external caches. Once all pending writes are completed, the processor then saves some of its register state to System Management Random Access Memory (SMRAM) and begins execution of an SMM handler, a software routine that performs low level functions, such as error reporting and logging, I/O emulation, suspend or resume operation, and power management.
SMRAM is memory that is reserved for SMM. The SMM handler is stored in SMRAM. Before execution of the SMM handler, the processor automatically stores some of its register state in a reserved portion of SMRAM. For example, the processor often stores the state of its segmentation registers, general purpose registers, instruction pointer, descriptor table registers, and model specific registers in the reserved portion of the SMRAM. Some register state, such as the floating point registers, may not be automatically stored upon entry to SMM since many SMM handlers do not modify these registers. However, if these registers are used in an SMM handler, code to store and restore these registers may be included in the SMM handler routine.
The SMM handler routine operates in a mode similar to Real mode. One difference between SMM and Real mode is that the 32-bit processor can address 4 gigabytes of address space in SMM. Real mode (and protected mode) are well-known to those familiar with Intel Architecture processors and those skilled in the art.
A RSM (Resume) instruction at the end of the SMM handler routine returns control to any interrupted program. During execution of the RSM instruction, the processor restores its state from the SMRAM and resumes execution of the interrupted routine. Since the internal state of the processor is restored and all memory accesses are to the SMRAM, this interrupt is transparent to both operating system and application software.
In the prior art, SMRAM is in a different memory space than the standard (non-SMM) memory space for SMM to be transparent to the operating system. The standard memory space typically addresses all of main memory. Rather than have a separate memory for the SMRAM, the SMRAM is typically stored in an unused portion of main memory, such as the graphics adapter memory. In some processors, the location of SMRAM is mapped to an address range within the SMRAM address space that corresponds to an unused portion of main memory. In some Intel Architecture processors, the initial SMRAM location is 00030000H (The "H" appended onto the end of the address indicates that the address is represented in hexadecimal). In the prior art, the graphics adapter memory address range corresponds to addresses A0000H to BFFFFH. Therefore, SMRAM addresses from 30000H to 4FFFFH are mapped to A0000H to BFFFFH. When accesses to addresses in the graphics adapter memory address range are made while in SMM, the request is directed through the memory controller to the main memory (SMM data). When accesses to addresses in the graphics adapter memory address range are made while not in SMM, the request is directed through a peripheral input/output (I/O) bridge to the graphics adapter memory on a video device (non-SMM data). Although data stored in SMRAM may have the same address as data stored in the standard address space, SMM data and non-SMM data corresponding to that address are distinct. Since cache memory distinguishes data elements by their address alone, there is no mechanism for distinguishing between the SMM data at a particular address and the non-SMM data at that same address even though both have distinct data.
If SMM data and non-SMM data were stored in the cache with no mechanism to distinguish them, data corruption problems may occur. When data at a particular address is written back from the cache, the memory subsystem cannot determine whether that data is SMM data or non-SMM data. For example, if the writeback data was SMM data, the memory subsystem should route it to the main memory. If the writeback data was non-SMM data, the memory subsystem should route it to a peripheral I/O device, for example. If the external system routes the writeback data incorrectly, the SMM data may be overwritten by non-SMM data or vice-versa, thereby corrupting the data at that address.
One prior art method to keep SMM data and non-SMM data distinct in the cache is to make SMM data and non-SMM data sharing the same address to be non-cacheable. The graphics adapter memory address range is an excellent candidate for such non-cacheable non-SMM memory. The graphics adapter memory is normally uncached because pixel data to be written to the display should be updated to the graphics adapter memory rather than be stored indefinitely in a writeback cache. In this method, the SMRAM sharing the same address range is also uncached. In this method, a cache flush is not required when switching between SMM and non-SMM, since SMM data is not stored in the cache. A disadvantage of this method is that non-cacheable bus cycles are slower than cacheable bus cycles. Although the latency is improved because flush operations are not necessary, the throughput of instructions and data is reduced because of the slower access times of non-cacheable cycles.
Another prior art method to keep SMM data and non-SMM data distinct has been to flush the cache when entering and leaving SMM. While in non-SMM, the processor generally performs cacheable bus cycles. When an SMI is recognized, a cache flush is performed prior to entering SMM to purge the cache of all non-SMM data so that SMM data may be cached. While in SMM, the processor generally performs cacheable bus cycles. When an RSM has been received, a cache flush is performed prior to leaving SMM to purge the cache of all SMM data so that non-SMM data may be cached. In SMM, the cache only contains SMM data. In non-SMM, the cache only contains non-SMM data. The advantage of this method is that SMM and non-SMM bus cycles can be cached, resulting in faster access times. However, the cache flushes required to enter and exit SMM take a long time, leading to increased latency of the system management handler. This may be a problem for SMM handlers that are required to respond quickly and for interrupt handlers that cannot afford to be disabled through two lengthy cache flushes. For example, a real-time operating system requires a low latency in order to respond to events in real-time. In addition, real-time applications such as audio playback, speech recognition, modem emulation including digital simultaneous voice and data (DVSD) and video conferencing, for example, require low latency as well. The consequences of increased latency may be "tears" and "frame drop outs" in video applications and shortened sounds and other aural artifacts in audio applications. En addition, increased latency may also cause data corruption, system crashes, and loss of critical services.
What is needed is a method to allow SMM data and non-SMM data to be stored in the cache without data corruption problems while avoiding cache flush operations when switching between SMM and non-SMM. Furthermore, what is needed is a method to reduce latency and increase performance of SMM handler routines.